[アップデート]EKS にノードの自動修復機能が追加されました
EKS にノードの自動修復機能が追加されました。
本機能を有効化することにより、EKS ノードに問題が生じた際に自動でノードを再作成することができます。
合わせて EKS アドオンとしてノード監視エージェント(eks-node-monitoring-agent)が追加され、ノードログから詳細な情報を取得できるようになりました。
自動修復とノード監視エージェントについて
自動修復を有効にすることで、EKS ノードが Ready であるかどうかを確認して、異常がある場合にノードを更新することができます。
kubectl get node で取得できる、いわゆる各ノードの状態ですね。
% kubectl get node
NAME STATUS ROLES AGE VERSION
ip-192-168-61-169.ap-northeast-1.compute.internal Ready <none> 18m v1.31.3-eks-59bf375
ip-192-168-66-205.ap-northeast-1.compute.internal Ready <none> 136m v1.31.3-eks-59bf375
この情報は kubelet が定期的に情報を送信するものであるため、追加のコンポーネントは不要で利用することができます。
自動修復単体で利用しても良いのですが、ノード監視エージェントをアドオンとして追加することで、ノードのログ情報を取得してより詳細な情報を確認できるようになります(PID の枯渇や、GPU ノードの NVIDIA ドライバ異常など)。
ノード監視エージェントが検知した「より詳細なイベント」に対しても自動修復をキックできるため、自動修復の対象範囲が広がる形になります。
By itself, node auto repair can react to the Ready condition of the kubelet and any node objects that are manually deleted. When paired with the node monitoring agent, node auto repair can react to more conditions that wouldn’t be detected otherwise. These additional conditions include KernelReady, NetworkingReady, and StorageReady.
https://docs.aws.amazon.com/eks/latest/userguide/node-health.html#node-auto-repair
また、ノード監視エージェントをインストールすることで、自動修復はキックしないものの、ノードに対して影響があるイベントを確認できます。
詳しい検知項目はEnable node auto repair and investigate node health issues にまとまっており、Severity が Event のものは検知のみで自動修復なし、Condition のものは自動修復ありのイベントになるようです。
イベントを検知してから自動修復を行うまでに、基本 30 分の猶予を設けるようです。
一部 NVIDIA ドライバー関連のイベントは猶予期間が短く、10 分となります。
既に障害が起きているノードであれば、即座に取り替えて欲しいくらいの気持ちになりそうですが、ノードに異常があってもそのノードに Pod が配置されないだけでシステム全体として落ちるわけではない(落ちないように設計すべき)と考えると、このくらいがちょうど良いのかもしれません。
Amazon EKS waits 10 minutes before acting on the AcceleratedHardwareReady NodeConditions, and 30 minutes for all other conditions.
https://docs.aws.amazon.com/eks/latest/userguide/node-health.html#node-auto-repair
ちなみに、Auto Mode の場合は特に設定しなくても両方の機能が有効になります。
EKS Auto Mode comes with both the node monitoring agent and node auto-repair enabled.
https://aws.amazon.com/jp/about-aws/whats-new/2024/12/node-health-monitoring-auto-repair-amazon-eks/
そもそも Auto Mode では EKS ノードの管理が AWS の責務になっているので、こちらが有効になっていてもいなくてもあまり意識することはないかもしれませんが...
(参考)EKS Auto Mode! | AWS RE:INVENT 2024 RECAP IN ZOZO
非 Auto Mode のクラスターを運用している場合は、構成を大きく変えずに運用負荷を下げることができるので、特にメリットが大きそうですね。
やってみた
では実際に試してみます。
非 Auto Mode の EKS クラスターを eksctl で作成します。
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: test-cluster
region: ap-northeast-1
version: "1.31"
iam:
withOIDC: true
cloudWatch:
clusterLogging:
enableTypes:
- "audit"
- "authenticator"
- "controllerManager"
- "scheduler"
managedNodeGroups:
- name: ng-1
nodeRepairConfig:
enabled: true
autoModeConfig:
enabled: false
v0.199.0 で自動修復を有効化して作成できるようになっているので、指定しておきます(相変わらず対応が速い!)。
また、ノード監視エージェントアドオンを追加します。
eksctl create addon --name eks-node-monitoring-agent --version 1.0.0 --cluster test-cluster
本アドオンは IAM 権限不要でインストールできます。
This add-on doesn’t require additional permissions.
https://docs.aws.amazon.com/eks/latest/userguide/workloads-add-ons-available-eks.html#add-ons-eks-node-monitoring-agent
実際にどのような情報の流れになっているのかはわかりませんが、kubelet 経由等で EC2 のロールを利用して EKS に情報を送る感じでしょうか。
セットアップが完了したので、EKS ノードに障害を模擬してみます。
今回は iptable を修正して、EKS ノード内のコンポーネントが EC2 のロールを利用できなくしてみます。
sudo yum -y install iptables-service
sudo iptables -I OUTPUT 1 -p tcp -d 169.254.169.254 -j DROP
sudo service iptables save
sudo service iptables restart
コマンド実行後、ノードのステータスが NotReady に変わりました。
% kubectl get node
NAME STATUS ROLES AGE VERSION
ip-192-168-57-100.ap-northeast-1.compute.internal NotReady <none> 108m v1.31.3-eks-59bf375
ip-192-168-66-205.ap-northeast-1.compute.internal Ready <none> 83m v1.31.3-eks-59bf375
また、iptable に問題を起こしそうなルールが追加されたよ!とノード監視エージェントが検知していました。
An unexpected REJECT` or DROP rule was found in the iptables, potentially blocking expected traffic.
https://docs.aws.amazon.com/eks/latest/userguide/node-health.html
かなり細かくノード異常の原因を検知してくれるので、トラブルシューティングが捗りますね。
とはいえ、今回は自動修復を試してみたいので 30 分放っておきます。
30 分強経過した所で、 TerminateInstanceInAutoScalingGroup
がコールされて、EKS ノードが自動で再作成されました!
ノードの状態も Ready になってますね。
TerminateInstanceInAutoScalingGroup
の詳細を CloudTrail で確認すると下記内容でした。
ノード監視エージェントや kubelet からの情報を元に EKS がサービスロール経由で自動修復を行ってました。
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAR5DGWODCNOJPW6PDC:EKS",
"arn": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWSServiceRoleForAmazonEKSNodegroup/EKS",
"accountId": "xxxxxxxxxxxx",
"accessKeyId": "xxxxxxxxxxxx",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "xxxxxxxxxxxx",
"arn": "arn:aws:iam::xxxxxxxxxxxx:role/aws-service-role/eks-nodegroup.amazonaws.com/AWSServiceRoleForAmazonEKSNodegroup",
"accountId": "xxxxxxxxxxxx",
"userName": "AWSServiceRoleForAmazonEKSNodegroup"
},
"webIdFederationData": {},
"attributes": {
"creationDate": "2024-12-28T14:06:13Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "eks-nodegroup.amazonaws.com"
},
"eventTime": "2024-12-28T14:06:13Z",
"eventSource": "autoscaling.amazonaws.com",
"eventName": "TerminateInstanceInAutoScalingGroup",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "eks-nodegroup.amazonaws.com",
"userAgent": "eks-nodegroup.amazonaws.com",
"requestParameters": {
"instanceId": "i-0ab76e62066c9730c",
"shouldDecrementDesiredCapacity": false
},
"responseElements": {
"activity": {
"activityId": "67365036-5b2d-8de5-5b3d-fd971340ead8",
"autoScalingGroupName": "eks-ng-1-86ca0689-78c9-a180-dc93-a98a44d722f9",
"description": "Terminating EC2 instance: i-0ab76e62066c9730c",
"cause": "At 2024-12-28T14:06:13Z instance i-0ab76e62066c9730c was taken out of service in response to a user request.",
"startTime": "Dec 28, 2024, 2:06:13 PM",
"statusCode": "InProgress",
"progress": 0,
"details": "{\"Subnet ID\":\"subnet-01ebf5952252d7977\",\"Availability Zone\":\"ap-northeast-1d\"}"
}
},
"requestID": "e9d58984-4b88-4f0e-8796-59b45d1a493c",
"eventID": "af848fef-390b-497f-9cc6-5305bc6fb6d1",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "xxxxxxxxxxxx",
"eventCategory": "Management"
}
最後に
EKS の自動修復について試してみました。
ノード監視エージェントも合わせて、有効化しておいて損はない機能に思います。
Auto Mode を利用する場合はあまり意識する必要がないかもしれないですが、裏で動いている仕組みへの理解が深まって嬉しいです!
このブログがどなたかの参考になれば幸いです。